home *** CD-ROM | disk | FTP | other *** search
/ PC Graphics Unleashed / PC Graphics Unleashed.iso / ch18 / rtrace / readme.nff < prev    next >
Text File  |  1992-11-02  |  26KB  |  502 lines

  1. STANDARD PROCEDURAL DATABASES, by Eric Haines, 3D/Eye, Inc.
  2.  
  3. [Created while under contract to Hewlett-Packard FSD and HP Laboratories]
  4. Version 3.1, as of 11/2/92
  5.     address: 3D/Eye, Inc., 2359 N. Triphammer Rd, Ithaca, NY 14850
  6.     email: erich@eye.com, wrath.cs.cornell.edu!eye!erich
  7.  
  8. This software package is not copyrighted and can be used freely.
  9.  
  10. History
  11. -------
  12. Versions 1.0 to 1.5 released February to June, 1987 for testing.
  13. Version 2.0 released July, 1987.
  14. Version 2.1 released August, 1987 - corrected info on speed of the HP 320,
  15.     other minor changes to README.
  16. Version 2.2 released November, 1987 - shortened file names to <=12 characters,
  17.     procedure names to <= 32 characters, and ensured that all lines are <= 80
  18.     characters (including return character).
  19. Version 2.3 released March, 1988 - corrected gears.c to avoid interpenetration,
  20.     corrected and added further instructions and global statistics for ray
  21.     tracing to README.
  22. Version 2.4 released May, 1988 - fixed hashing function for mountain.c.
  23. Version 2.5 released October, 1988 - added NFF documentation.
  24. Version 2.6 released August, 1989 - lib_output_cylcone fix (start_norm.w was
  25.     not initialized).
  26. Version 2.7 released July, 1990 - comment correction in lib.c, NFF file
  27.     clarifications.
  28. Version 3.0 released October, 1990 - added teapot.c database, mountain.c
  29.     changed to mount.c, additions to def.h and lib.c, changes to README and
  30.     NFF, added patchlevel.h file.
  31. Version 3.1 released November, 1992 - minor typo fixes, updated FTP list,
  32.     makefile update
  33.  
  34. {These files use tab characters worth 8 spaces}
  35.  
  36.  
  37. Introduction
  38. ------------
  39.  
  40.     This software is meant to act as a set of basic test images for ray
  41. tracing algorithms.  The programs generate databases of objects which are
  42. fairly familiar and "standard" to the graphics community, such as the teapot,
  43. a fractal mountain, a tree, a recursively built tetrahedral structure, etc.  I
  44. originally created them for my own testing of ray tracing efficiency schemes.
  45. Since their first release other researchers have used them to test new
  46. algorithms.  In this way, research on algorithmic improvements can be compared
  47. in a more standardized way.  If one researcher ray-traces a car, another a
  48. tree, the question arises, "How many cars to the tree?"  With these databases
  49. we may be comparing oranges and apples ("how many hypercubes to a timeshared
  50. VAX?"), but it's better than comparing oranges and orangutans.  In addition,
  51. this document outlines some statistics that are more meaningful to researchers
  52. than raw timing tests.  Using these statistics along with the same scenes
  53. allows us to compare results in a more meaningful way.
  54.  
  55.     With the development and release of the Anderson benchmarks for graphics
  56. hardware, the use of the SPD package for hardware testing is somewhat
  57. redundant.  Therefore I have deleted references to testing hidden-surface
  58. algorithms in this version.  However, another interesting use for the SPD has
  59. been noted:  debugging.  By comparing the images and the statistics with the
  60. output of your own ray tracer, you can detect program errors.  For example,
  61. "mount" is useful for checking if refraction rays are generated correctly, and
  62. "balls" can check for the correctness of eye and reflection rays.
  63.  
  64.     The images for these databases and other information about them can be
  65. found in "A Proposal for Standard Graphics Environments," IEEE Computer
  66. Graphics and Applications, vol. 7, no. 11, November 1987, pp.  3-5.  See
  67. IEEE CG&A, vol. 8, no. 1, January 1988, p. 18 for the correct image of the
  68. tree database (the only difference is that the sky is blue, not orange).  The
  69. teapot database was added later, and consists of a shiny teapot on a shiny
  70. checkerboard.
  71.  
  72.     The SPD package is available via anonymous FTP from:
  73.  
  74.     freedom.graphics.cornell.edu [128.84.247.85]
  75.     weedeater.math.yale.edu [130.132.23.17]
  76.     cs.uoregon.edu [128.223.4.13]
  77.  
  78. among others.  For those without FTP access, write to the netlib automatic
  79. mailer:  research!netlib and netlib@ornl.gov are the sites.  Send a one line
  80. message "send index" for more information, or "send haines from graphics" for
  81. the latest version of the SPD package.
  82.  
  83.  
  84. File Structure
  85. --------------
  86.  
  87.     Eight different procedural database generators are included.  These were
  88. designed to span a fair range of primitives, modeling structures, lighting and
  89. surface parameters, background conditions, and other factors.  A complexity
  90. factor is provided within each program to control the size of the database
  91. generated.
  92.  
  93. This software package contains the following files:
  94.  
  95.     README - what you are now reading
  96.     NFF - a description of the Neutral File Format used in the SPD
  97.     patchlevel.h - keeps track of patch level
  98.     makefile - used to make the programs (in HP-UX Unix)
  99.     def.h - some useful "C" definitions
  100.     lib.h - globals and library routine declarations
  101.     lib.c - library of routines
  102.     balls.c - fractal ball object (a.k.a. sphereflake) generator
  103.     gears.c - 3D array of interlocking gears generator
  104.     mount.c - fractal mountain and 4 glass ball generator
  105.     rings.c - pyramid of dodecahedral rings generator
  106.     teapot.c - the famous teapot on a checkerboard generator
  107.     tetra.c - recursive tetrahedra generator
  108.     tree.c - tree generator
  109.  
  110.     The compiled and linked programs will output a database in ASCII to stdout
  111. containing viewing parameters, lighting conditions, material properties, and
  112. geometric information.  The data format is called the 'neutral file format'
  113. (or NFF) and is described in the `NFF' file.  This format is meant to be
  114. minimal and easy to attach to a user-written filter program which will convert
  115. the output into a file format of your choosing.
  116.  
  117.     Either of two sets of primitives can be selected for output.  If
  118. OUTPUT_FORMAT is defined as OUTPUT_CURVES, the primitives are spheres, cones,
  119. cylinders, and polygons.  If OUTPUT_FORMAT is set to OUTPUT_PATCHES, the
  120. primitives are output as polygonal patches and polygons (i.e.  all other
  121. primitives are polygonalized).  In this case OUTPUT_RESOLUTION is used to set
  122. the amount of polygonalization of non-polygonal primitives.  In general,
  123. OUTPUT_CURVES is used for ray-trace timing tests, and OUTPUT_PATCHES for
  124. polygon-based algorithm timings.  Note that sphere primitives are not
  125. polygonalized using the simple longitude/latitude tessellation, but rather are
  126. chopped along the six faces of a cube projected onto the sphere.  This
  127. tessellation avoids generation of the cusp points at the sphere's poles and so
  128. eliminates discontinuities due to them.
  129.  
  130.     The size factor is used to control the overall size of the database.
  131. Default values have been chosen such that the maximum number of primitives
  132. less than 10,000 is output.  One purpose of the size factor is to avoid
  133. limiting the uses of these databases.  Depending on the research being done
  134. and the computing facilities available, a larger or smaller number of
  135. primitives may be desired.  The size factor can also be used to show how an
  136. algorithm's time changes as the complexity increases.
  137.  
  138.     To generate the databases, simply type the name of the database and direct
  139. the output as desired, e.g. "balls > balls.nff" creates the default sized
  140. database and sends the output to balls.nff.  A new feature in 3.0 is that you
  141. can enter the size factor on the command line, e.g. "balls 2 > balls.nff"
  142. gives a much smaller database of 91 spheres.  See the header of the database C
  143. file (e.g. "balls.c") for how the size factor affects the output.
  144.  
  145.     Other parameters in the code itself (for example, branching angles for
  146. "tree.c" and the fractal dimension in "mount.c") are included for your own
  147. enjoyment, and so normally should not be changed if the database is used for
  148. timing tests.  Because the hashing function in the original release of
  149. "mount.c" is not very good (at low resolutions there is patterning), there is
  150. a better hashing function provided which can be turned on by defining
  151. NEW_HASH.  Use the old hashing function (i.e.  don't change anything) for
  152. consistency with previously published results.
  153.  
  154.     Since the SPD package is designed to test efficiency, the actual shading
  155. of the images is mostly irrelevant.  All that matters is that reflective
  156. surfaces spawn reflection rays and transmitters spawn refraction rays.  For
  157. this reason the effect of the other shading parameters is up to the
  158. implementer.  Note that light intensities, ambient components, etc. are not
  159. specified.  These may be set however you prefer.  Feel free to change any
  160. colors you wish (especially the garish colors of `rings').  The thrust of
  161. these databases is the testing of rendering speeds, and so the actual color
  162. should not affect these calculations.  An ambient component should be used for
  163. all objects, so that the time to compute it is included in the ray tracing
  164. statistics.  A simple formula for a relative intensity (i.e. between 0 and
  165. 1) for each light and for the ambient component is the following:
  166.  
  167.     sqrt(# lights) / (# lights * 2).
  168.  
  169.     If you desire a model for a good scene description language, NFF is not
  170. it.  Instead, you should look at Craig Kolb's ray-tracer language, which is
  171. part of his excellent RayShade ray tracer, available via anonymous FTP from
  172. weedeater.math.yale.edu [130.132.23.17].  Of the public domain ray tracers,
  173. this is the one to beat in speed.  Also included in his distribution is an awk
  174. filter which converts NFF files to his language.
  175.  
  176.     The programs all attempt to minimize program size (for ease in
  177. distributing) and memory usage, and none allocate any dynamic memory.  As
  178. such, many of the programs are relatively inefficient, regenerating various
  179. data again and again instead of saving intermediate results.  This behavior
  180. was felt to be unimportant, since generating the data is a one-time affair
  181. which normally takes much less time than actually rendering the scene.
  182.  
  183.  
  184. Database Analysis
  185. -----------------
  186.  
  187.     The databases were designed with the idea of diversity in mind.  The
  188. variables considered important were the amount of background visible, the
  189. number of lights, the distribution of sizes of objects, the amount of
  190. reflection and refraction, and the depth complexity (how many objects a ray
  191. from the eye passes through).
  192.  
  193. balls:  This database is sometimes called "sphereflake", as it is generated
  194.     like a snowflake curve.  This database consists mostly of various sized
  195.     spheres.  It has no eye rays which hit the background, and the three light
  196.     sources cause a large number of shadow rays to be generated.
  197.  
  198. gears:  This database consists of a set of meshed gears.  Some of the gears
  199.     are transmitters, making this database lengthy to render.  The gear faces
  200.     each have 144 vertices, and thus tests polygon inside/outside test
  201.     efficiency.  Depth complexity is medium.
  202.  
  203. mount:  The fractal mountain generator is derived from Loren Carpenter's
  204.     method, and the composition with the four glass spheres is inspired by
  205.     Peter Watterberg's work.  Most objects are tiny (i.e. fractal facets),
  206.     but rendering time is dominated by the rendering of the four large
  207.     spheres.  Depth complexity is low, and there is much background area.
  208.  
  209. rings:  Objects with six pentagonal rings form a pyramid against a background
  210.     polygon.  With a high amount of interreflection and shadowing, this scene
  211.     is fairly lengthy to render.  Depth complexity is also high, with
  212.     all of the objects partially or fully obscured.
  213.  
  214. teapot:  The famous teapot on a checkerboard.  There are a number of
  215.     variations on the teapot database, i.e.  whether the bottom is included
  216.     (the IEEE CG&A article added a bottom), variations in the control points
  217.     on the lid (which creates thin, almost degenerate triangles), etc.  For
  218.     this database generator, the bottom is created, and the degenerate
  219.     polygonal patches at the center of the lid and bottom are not output.  The
  220.     bottom of the teapot is not flat, interestingly enough.  The resolution of
  221.     the checkerboard shows the resolution of the teapot meshing (with each
  222.     teapot quadrilateral cut into two triangles), e.g. an 8x8 checkerboard
  223.     means that 8x8x2 triangles are generated per patch.  The definitions for
  224.     the 32 Bezier patches are a part of the program.  All objects are
  225.     reflective and there are two light sources.  Depth complexity is low.
  226.  
  227. tetra:  A recursive tetrahedral pyramid, first visualized by Benoit Mandelbrot
  228.     and Alan Norton.  This scene is dominated by background (around 80%).  With
  229.     the objects not being reflective and there being only one light source,
  230.     this database is particularly quick to render, with various forms of
  231.     coherency being very useful.  Depth complexity is medium, though some
  232.     rays must pass by many triangles for some of the background pixels.
  233.  
  234. tree:  A tree formed using Aono and Kunii's tree generation method.  With
  235.     seven light sources, the emphasis is on shadow testing.  Shadow caching
  236.     yields little improvement due to the narrow primitives, and many shadow
  237.     rays pass through complex areas without hitting any objects.  There is a
  238.     fair amount of background area.  Depth complexity is low.
  239.  
  240.  
  241.                 balls      gears       mount       rings
  242.                 -----      -----       -----       -----
  243. primitives        SP         P           PS         YSP
  244. total prim.      7382       9345        8196        8401
  245. poly/patches    1417K       9345        8960        874K
  246.  
  247. lights            3          5           1           3
  248. background        0%         7%         34%          0%
  249. specular         yes        yes         yes         yes
  250. transmitter       no        yes         yes          no
  251.  
  252. eye hit rays   263169     245086      173125      263169
  253. reflect rays   175095     304643      354769      315236
  254. refract rays        0     207564      354769           0
  255. shadow rays    954368    2246955      412922     1085002
  256.  
  257.  
  258.                teapot       tetra        tree
  259.                ------       -----        ----
  260. primitives       TP           P           OSP
  261. total prim.      9264        4096        8191
  262. poly/patches     9264        4096        852K
  263.  
  264. lights            2           1           7
  265. background       39%         81%         35%
  266. reflector        yes          no          no
  267. transmitter       no          no          no
  268.  
  269. eye hit rays   161120       49788      169836
  270. reflect rays   225248           0           0
  271. refract rays        0           0           0
  272. shadow rays    407656       46112     1097419
  273.  
  274.  
  275.     "primitives" are S=sphere, P=polygon, T=polygonal patch, Y=cylinder,
  276. O=cone, listed from most in database to least.
  277.  
  278.     "total prim." is the total number of ray-tracing primitives (polygons,
  279. spheres, cylinders and cones) in the scene.  The number of polygons and vectors
  280. generated is a function of the OUTPUT_RESOLUTION.  The default value for this
  281. parameter is 4 for all databases.
  282.  
  283.     "poly/patches" is the total number of polygons and polygonal patches
  284. generated when using OUTPUT_PATCHES.
  285.  
  286.     "lights" is simply the number of lights in a scene.  "background" is the
  287. percentage of background color (empty space) seen directly by the eye for the
  288. given view.  "reflector" tells if there are reflective objects in the scene,
  289. and "transmitter" if there are transparent objects.
  290.  
  291.     "eye hit rays" is the number of rays from the eye which actually hit an
  292. object (i.e. not the background).  513x513 eye rays are assumed to be shot
  293. (i.e. one ray per pixel corner).  "reflect rays" is the total number of rays
  294. generated by reflection off of reflecting and transmitting surfaces.  "refract
  295. rays" is the number of rays generated by transmitting surfaces.  "shadow rays"
  296. is the sum total of rays shot towards the lights.  Note that if a surface is
  297. facing away from a light, or the background is hit, a light ray is not formed.
  298. The numbers given can vary noticeably from a given ray tracer, but should all
  299. be within about 10%.
  300.  
  301.     "K" means exactly 1000 (not 1024), with number rounded to the nearest K.
  302. All of the above statistics should be approximately the same for all
  303. classical ray tracers.
  304.  
  305.  
  306. Testing Procedures
  307. ------------------
  308.  
  309. Below are listed the requirements for testing various algorithms.  These test
  310. conditions should be realizable by most renderers, and are meant to represent
  311. a common mode of operation for each algorithm.  Special features which the
  312. software supports (or standard features which it lacks) should be noted in
  313. your statistics.
  314.  
  315.     1)  The non-polygon (OUTPUT_CURVES) format should normally be used for
  316.     ray-tracing tests.
  317.  
  318.     2)  All opaque (non-transmitting) primitives can be considered one-sided
  319.     for rendering purposes.  Only the outside of primitives are visible in
  320.     the scenes.  The only exception to this is the "teapot" database, in
  321.     which the teapot itself should normally be double sided (this is
  322.     necessary because the lid of the teapot does not fit tightly, allowing
  323.     the viewer to see back faces).
  324.  
  325.     3)  Polygonal patches (which are always triangles in the SPD) should have
  326.     smooth shading, if available.
  327.  
  328.     4)  Specular highlighting should be performed for surfaces with a
  329.     reflective component.  The simple Phong distribution model is
  330.     sufficient.
  331.  
  332.     5)  Light sources are positional.  If unavailable, assign the directional
  333.     lights a vector given by the light position and the viewing "lookat"
  334.     position.
  335.  
  336.     6)  Render at a resolution of 512 x 512 pixels, shooting rays at the
  337.     corners (meaning that 513 x 513 eye rays will be created).  The four
  338.     corner contributions are averaged to arrive at a pixel value.  If
  339.     rendering is done differently, note this fact.  No pixel subdivision
  340.     is performed.
  341.  
  342.     7)  The maximum tree depth is 5 (where the eye ray is of depth 1).  Beyond
  343.     this depth rays do not have to be spawned.
  344.  
  345.     8)  All rays hitting only reflective and transmitting objects spawn
  346.     reflection rays, unless the maximum ray depth was reached by the
  347.     spawning ray.  No adaptive tree depth cutoff is allowed; that is, all
  348.     rays must be spawned (adaptive tree depth is a proven time saver and
  349.     is also dependent on the color model used - see Roy Hall's work for
  350.     details).
  351.  
  352.     9)  All rays hitting transmitting objects spawn refraction rays, unless
  353.     the maximum ray depth was reached or total internal reflection occurs.
  354.     Transmitting rays should be refracted using Snell's Law (i.e. should
  355.     not pass straight through an object).  If total internal reflection
  356.     occurs, a reflection ray should still be generated at this node.  Note
  357.     that all transmitters in the SPD are also reflective, but this is
  358.     not a requirement of the file format itself.
  359.  
  360.     10) A shadow ray is not generated if the surface normal points away from
  361.     the light.  This is true even on transmitting surfaces.  Note any
  362.     changes from this condition.
  363.  
  364.     11) Assume no hierarchy is given with the database (for example, color
  365.     change cannot be used to note a clustering).  The ray tracing program
  366.     itself can create its own hierarchy, but this process should be
  367.     automatic.  Note any exceptions to this (e.g. not including the
  368.     background polygon in the efficiency structure, changing the
  369.     background polygon into an infinite plane, etc).  Such changes can be
  370.     critical for the efficiency of some schemes, so an explanation of why
  371.     changes were made is important.
  372.  
  373.     12) Timing costs should be separated into at least two areas: preprocessing
  374.     and ray-tracing.  Preprocessing includes all time spent initializing,
  375.     reading the database, and creating data structures needed to ray-trace.
  376.     Preprocessing should be all the constant cost operations--those that
  377.     do not change with the resolution of the image.  Ray-tracing is the
  378.     time actually spent tracing the rays (i.e. everything that is not
  379.     preprocessing).
  380.  
  381.     13) Other timing costs which would be of interest are in a breakdown of
  382.     times spent in preprocessing and during actual ray-tracing.  Examples
  383.     include time spent reading in the data itself, creating a hierarchy,
  384.     octree, or item buffer, and times spent on intersection the various
  385.     primitives and on calculating the shade.
  386.  
  387.     14) Time-independent statistics on the performance of the algorithm should
  388.     be gathered.  Some examples are the number of ray/object intersection
  389.     tests, the number of ray/object tests which actually hit objects,
  390.     number of octree or grid nodes accessed, and the number of successful
  391.     shadow cache hits.
  392.  
  393.  
  394. Timings
  395. -------
  396.  
  397. Rendering time of the ray-traced test set on an HP-835, optimized (512 x 512):
  398.  
  399.        Input   Setup  Ray-Tracing  |  Polygon   Sphere    Cyl/Cone    Bounding
  400.             (hr:min:sec)           |   Tests     Tests      Tests    Box Tests
  401. -------------------------------------------------------------------------------
  402. balls   0:14    0:19      24:56    |    822K     6197K        0        51726K
  403. gears   0:56    0:18    1:02:31    |  13703K       0          0       107105K
  404. mount   0:31    0:14      18:49    |   4076K     3978K        0        31106K
  405. rings   0:41    0:33      53:41    |   1045K     5315K     16298K      91591K
  406. teapot  1:02    0:18      25:38    |   7281K       0          0        57050K
  407. tetra   0:15    0:06       3:48    |    965K       0          0         7637K
  408. tree    0:40    0:31      11:36    |    479K      524K      1319K      22002K
  409.  
  410. Input:  time spent reading in the NFF file.
  411.  
  412. Setup:  time spent creating the database and any ray tracing efficiency
  413. structures, and cleaning up after ray trace (does not include "Input" time).
  414.  
  415. Ray-Tracing:  time spent traversing and rendering the pixel grid.
  416.  
  417.  
  418. A typical set of ray tracing intersection statistics for the tetra database is:
  419.  
  420. [these statistics should be the same for all users]
  421.   image size: 512 x 512
  422.   total number of pixels: 262144            [ 512 x 512 ]
  423.   total number of trees generated: 263169        [ 513 x 513 ]
  424.   total number of tree rays generated: 263169        [ no rays spawned ]
  425.   number of eye rays which hit background: 213381    [ 81% - might vary ]
  426.   average number of rays per tree: 1.000000
  427.   average number of rays per pixel: 1.003910
  428.   total number of shadow rays generated: 46111        [ might vary a bit ]
  429.  
  430. [these tests vary depending on the ray-tracing algorithm used]
  431. Intersector performance
  432.   Bounding box intersections:      7636497  -    26.71 usec/test
  433.   Polygon intersections:            964567  -    36.77 usec/test
  434.  
  435. Ray generation
  436.   Eye rays generated:              263169 ( 49788 hit - 18.92% )
  437.   Reflection rays generated:            0
  438.   Refraction rays generated:            0
  439.   Shadow rays generated:            46111
  440.       Coherency hits:                3407  -  7.39 % of total
  441.       Fully tested:                 42704
  442.  
  443.  
  444.     The ray-tracer which generated these statistics is based on hierarchical
  445. bounding boxes generated using Goldsmith & Salmon's automatic hierarchy method
  446. (see IEEE CG&A May 1987).  It no longer uses an item buffer, hence the higher
  447. number of overall intersection tests from earlier SPD versions.
  448.  
  449.     One problem worth analyzing when using the SPD for efficiency tests is how
  450. octree, SEADS, and other space dividing algorithms perform when the background
  451. polygon dimensions are changed (thus changing the size of the outermost
  452. enclosing box, which changes the encoding of the environment).  One analysis of
  453. the effect of the background polygon on RayShade can be found in "Ray Tracing
  454. News", volume 3, number 1.
  455.  
  456.  
  457. Future Work
  458. -----------
  459.  
  460.     These databases are not meant to be the ultimate in standards, but are
  461. presented as an attempt at providing representative modeled environments.  A
  462. number of extensions to the file format could be provided someday, along with
  463. new database generators which use them.  The present databases do not contain
  464. polygons with holes, spline patches, polygonal mesh, triangular strip, or
  465. polyhedron data structures.  Modeling matrices are not output, and CSG
  466. combined primitives are not included.  Light sources are particularly
  467. simplistic.  For a richer, more user-friendly scene description language,
  468. take a look at RayShade or RenderMan.
  469.  
  470.     As far as database geometry is concerned, most scenes have a preponderance
  471. of small primitives.  If you find that these databases do not reflect the type
  472. of environments you render, please write and explain why (or better yet, write
  473. one or more programs that will generate your "typical" environments--maybe it
  474. will get put in the next release).
  475.  
  476.  
  477. Acknowledgements
  478. ----------------
  479.  
  480.     I originally heard of the idea of standard scenes from Don Greenberg back
  481. in 1984.  Some time earlier he and Ed Catmull had talked over coming up with
  482. some standard databases for testing algorithmic claims, and to them must go
  483. the credit for the basic concept.  The idea of making small programs which
  484. generate the data came to me after Tim Kay generously sent huge files of his
  485. tree database via email - I felt there had to be a better way.  Adding the
  486. teapot was inspired by the repeated demand on comp.graphics for this database,
  487. certainly the most famous of all.
  488.  
  489.     Many thanks to the reviewers, listed alphabetically:  Kells Elmquist, Jeff
  490. Goldsmith, Donald Greenberg, David Hook, Craig Kolb, Susan Spach, Rick Speer,
  491. K.R. Subramanian, J. Eric Townsend, Mark VandeWettering, John Wallace, Greg
  492. Ward, and Louise Watson.  Other people who have kindly offered their ideas and
  493. opinions on this project include Brian Barsky, Andrew Glassner, Roy Hall, Chip
  494. Hatfield, Tim Kay, John Recker, Paul Strauss, and Chan Verbeck.  These names
  495. are mentioned mostly as a listing of people interested in this idea.  They do
  496. not necessarily agree (and in some cases strongly disagree) with the validity
  497. of the concept or the choice of databases.
  498.  
  499.     Your comments and suggestions on these databases are appreciated.  Please
  500. do send me any timing results for software and hardware which you test, or any
  501. publications which use the SPD package.
  502.